%-----------------------------------------------------------------------------
\chapter{Implementation}
%-----------------------------------------------------------------------------





\section{Chosen software}
The following software was chosen for implementation.


\subsection{MySQL}
Due to the fact that MySQL is one of the three most popular relational
databases, it can be used without any cost and it is the only open source
implementation among these three it was chosen for implementation.


\subsection{Java Spring framework}
Due to the facts that the Spring framework is an open source application
framework that aims to make the development of enterprise applications with
Java easier \cite{johnson2009professional} and furthermore it is very popular
\cite{learnquest} it was chosen for implementation.


\subsection{Hibernate}
Hibernate is the top most used object relational mapping solution with a large
distance to its competitors \cite{zeroturnaround}. Therefore it was chosen for
implementation too.


\section{Application to be refactored}
The following example application was created for refactoring purposes. It
consists of a table that holds basic customer data, a data source, a domain
layer and a presentation layer implementing a HTML application and a REST
interface. On the one hand its purpose is to reflect common technologies used
nowadays in Java enterprise applications that utilize a relational database in
conjunction with the Spring framework. On the other hand its purpose is to
demonstrate how the in the introduction described refactoring can be achieved.


\subsection{Database table layout}
The database contains one single table ``customer" that holds the following 6
columns, as shown in table ~\ref{table1}.

\begin{table}[htbp]
\begin{center}
\begin{tabular}{|l|l|l|} 
\hline 
Column name 		& Description 	 						& Data type		\\ 
\hline 
\hline
id 					& Primary key (unique identifier) 		&				\\
					&of the customer 		 				& Numeric		\\ 
\hline
name				& Full name of the customer				&				\\
					& consisting of first name and			&				\\ 
					& last name in one string.		 		& Alphanumeric 	\\
\hline
email				& Email address of the person			& Alphanumeric	\\ 
\hline
address				& Full address of the customer			&				\\ 
					& consisting of street, city, zip		&				\\
					& code and country in one string. 		& Alphanumeric 	\\
\hline
telephone\_number	& Customers telephone number  			& Alphanumeric	\\ 
\hline
sex					& Customers gender  					& Alphanumeric	\\ 
\hline
\end{tabular}
\end{center}
\caption{Tabular listing of database tables columns with explanation and data
type}
\label{table1}
\end{table}



%Haui
%Alles vor hier überprüfen
%Umschreiben
%Überprüfen


%Dieses Mal innen außen
%Danach Einleitung alles schreiben


\subsection{Data Source layer}
The Data Source layer consists of the so called entity class ``Customer'' whose
purpose is to reflect the described database table design in Java with its
corresponding getter and setter methods. In this context it is very important to
mark the class property who holds the primary key of the database table with the
``@Id'' Java Annotation.

\lstinputlisting[language=Java]{figures/Customer1.java}


Additionally it is necessary to create the Spring data repository to utilize
Hibernate in the background to do the object relational mapping in conjunction with the
entity class ``Customer''. Therefore only the interface ``CustomerRepository''
has to be created.

\lstinputlisting[language=Java]{figures/CustomerRepository1.java}


Via annotating it with ``@Repository'' the Spring framework is instructed to
create a Spring data Repository at start up time. Furthermore because of the
interface extends the Spring provided interface ``JpaRepository'' all methods
for creating, deleting and updating customer records - such as save, delete,
find etc. - are going to be provided automatically.





\subsection{Domain layer}
The domain layer consists of Java classes that encapsulate all business rules
with its regarding exception classes, an interface that describes the
customer domain class and the domain class for customers ``CustomerDomain''
itself. Special attention has to be paid to the shown Spring Framework specific
Java Annotations again. They do assure that at application start up all
components are wired together correctly. For example the variable
``customerRepository'' is initialized with an instance of the previous shown
class ``CustomerRepository'' automatically. Therefore the shown domain class
can interact with the database.
  
\lstinputlisting[language=Java]{figures/CustomerDomainImpl1.java}


\subsection{Presentation layer}
The presentation layer of the application consists of a HTML application, as shown in figure
~\ref{Label-0}, and an additional REST interface for data interchange.
\newline

\begin{figure}[htbp]
    \centering
    \includegraphics [width=12cm,angle=0] {figures/JavaServerFacesWebApplication.jpg}
    \caption{Picture of the HTML application front end}
    \label{Label-0}
\end{figure}

Utilizing the REST implementation class both front ends use the
``Customer\-Domain'' class of the previous described domain layer.


\lstinputlisting[language=Java]{figures/Rest1.java}



\subsection{Unit Tests}
To assure later on applied refactoring does not alter the behaviour of the
application and that the refactoring is not going to restrict given interfaces
of the data source layer towards its layers above unit tests for the domain
layer have been created.


\lstinputlisting[language=Java]{figures/UnitTests1.java}


Further the developed unit tests execute each line of code of the domain layer.





\section{Refactored application}
The following refactoring has been applied to the application.




\subsection{Database table layout}
In order to gain clearer separation of information and to enable future
improvements the following refactoring, as shown in figure ~\ref{Label-1}, has
been applied:

  \begin{enumerate}
    \item
    The column name has been split into the two columns ``firstname'' and
    ``lastname'' holding the previous contents of column ``name''.
    \item
    The table customers has been split into the table customers and the table
    address, the latter holding address information of customers.
    \item
    The two tables customers and address have a 1:1 relation, meaning for each
    customer only one address record can be saved.
    \item
    The table address further consists of the following distinct columns:
    ``street'', ``city'', ``zipcode'' and ``country'' resulting from an
    additional column split of previous single column ``address''.
  \end{enumerate}


\begin{figure}[htbp]
    \centering
    \includegraphics [width=12cm,angle=0] {figures/erdiagram.jpg}
    \caption{Illustration of refactored table structure with its relations}
    \label{Label-1}
\end{figure}

 


\subsection{Data Source layer}
The following changes have been applied on the data source layer of the Java
Spring application.

\subsubsection{New class ``CustomerRefactored''}
The class ``CustomerRefactored'' has been created to reflect the refactored
database table ``customer''. Due to the fact that the changed class
``CustomerRepositoryImpl'', see following sections, has to return the object ``Customer'' where the object
``CustomerRefactored'' was created from initially it is necessary that
``CustomerRefactored'' stores a reference to the referring class instance
``Customer''.

\lstinputlisting[language=Java]{figures/CustomerRefactored.java}


\subsubsection{New class ``Address''}
The entity ``Address'' holds address information previously stored in entity
``Customer''.

\lstinputlisting[language=Java]{figures/Address.java}



\subsubsection{New class ``CustomerRepositoryRefactored''}
Alike with the class ``Customer'' it is necessary to create a Spring data
repository utilizing an interface for class ``CustomerRefactored''.

\lstinputlisting[language=Java]{figures/CustomerRepositoryRefactored.java}



\subsubsection{Changes class ``Customer''}
The modified class ``Customer'' only remains existent and must not be changed in
a restrictive way - especially regarding its public methods and interfaces - 
because it is used by programs that reside on top of the Data Source layer, for example
the class ``CustomerDomainImpl'' which is part of the domain layer. Therefore it
delegates all logic to class ``CustomerRefactored'' which it creates an instance
of at creation time and stores a reference to. However, due to the fact that the
adapted class ``CustomerDomainImpl'', see following sections, still has to deal
with instances of the original class ``Customer'' and that the Spring data
repository utilizes Hibernate in the background the class still has to contain
the ``@Entity'' and ``@Id'' annotations.

\lstinputlisting[language=Java]{figures/Customer2.java}


\subsubsection{Changes ``CustomerRepository''}
The adapted Spring data repository ``CustomerRepository'' still has to accept
instances of class ``Customer'' but internally has to work with instances of
class ``CustomerRefactored''. Due to this fact its implementation cannot rely anymore
on the automatically by the Spring framework provided save, delete, find etc.
methods via extending the interface ``JpaRepository''. Therefore it extends the
self defined interface ``CustomerRepositoryLegacyMethods''.

\lstinputlisting[language=Java]{figures/CustomerRepository2.java}

The newly created interface itself extends Spring's interface ``JpaRepository''
and overrides all methods to work with objects of class ``Customer''.

\lstinputlisting[language=Java]{figures/CustomerRepositoryLegacyMethods.java}


Furthermore the implementation class ``CustomerRepositoryImpl'' additionally
extends the interface ``CustomerRepositoryLegacyMethods''. It accepts instances
of class ``Customer'', transfers it to instances of class ``CustomerRefactored''
and utilizes the Spring data repository ``CustomerRepositoryRefactored'' to
interact with the database and the refactored tables in the background.


\lstinputlisting[language=Java]{figures/CustomerRepositoryImpl.java}


This way by providing the implementation class ``CustomerRepositoryImpl'' for
the interface ``CustomerRepositoryLegacyMethods'' that is used by the interface
``CustomerRepository'' the Spring framework wires all together at application
start up automatically so the domain layer still can use the class
``CustomerRepository'' with its original interfaces.
\newline


Accordingly, the in the initial application defined repository does not
have to be changed regarding its from the outside world callable methods, but
internally works with different classes, structures and database tables.





\subsection{Domain layer}
As required by the task description and the objectives of this work no changes
have taken place on elements of the the domain layer.

\subsection{Presentation layer}
As required by the task description and the objectives of this work no changes
have taken place on elements of the the presentation layer.


%Unit Tests
%Test klein
\subsection{Unit tests}
No changes have been applied to the unit tests developed for the original
application.



%Nur aufzählen
%Bewertung später
%In Conclusion
%Dort machen










%Überlegen


%http://martinfowler.com/eaaCatalog/serviceLayer.html

%So machen?
%Überlegen
%Code erstellen
%Danach http://martinfowler.com/ieeeSoftware/coupling.pdf



%http://martinfowler.com/eaaCatalog/







%Nicht
%\section{Alternative Implementations}






